home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 11627 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: newdelph.cig.mot.com!coypu!bhttchry
  2. From: bhttchry@coypu.cig.mot.com (Soumya Bhattacharya)
  3. Newsgroups: comp.lang.c
  4. Subject: Query about the #line preprocessor directive
  5. Date: 25 Mar 1996 12:08:17 GMT
  6. Organization: Cellular Infrastructure Group, Motorola
  7. Message-ID: <4j62bh$svj@newdelph.cig.mot.com>
  8. NNTP-Posting-Host: coypu.cig.mot.com
  9.  
  10. Dear Readers,
  11.  
  12.     I had implemented an ANSI C preprocessor. I am trying this sample
  13. program with my preprocessor:
  14.  
  15. -------------------------
  16. #line /* This is 
  17. a multiline 
  18. comment 
  19. nicely 
  20. done */ 100
  21. __LINE__
  22. --------------------------
  23.  
  24. The output produced by my preprocessor is:
  25.  
  26. --------------------------------
  27. # 1 "1.c" 
  28. /* This is 
  29. a multiline 
  30. comment 
  31. nicely 
  32. done */#  100
  33. 104
  34. -------------------------------
  35.  
  36.     Whereas gcc's (ANSI C conformant) preprocessor produces:
  37.  
  38. ----------------------------------
  39. # 1 "1.c"
  40. /* This is 
  41. a multiline 
  42. comment 
  43. nicely 
  44. done */
  45. # 99 "1.c"
  46.  
  47. 100
  48. ---------------------------------
  49.  
  50.     
  51.  
  52.     The thing is that the line containing the #line directive had this 
  53. multiline comment. The ANSI standard book in the section describing #line
  54. directive says (section 6.8.4)
  55.  
  56.     "... the directive causes the implementation to behave as if
  57. the following sequence of source lines begins with a source line that
  58. has a line number as specified by the digit sequence..."
  59.  
  60.     In the same place it defines "line number" as "...one greater
  61. than the number of new-line characters read or introduced in the
  62. translation phase..."
  63.  
  64.     In usual cases, multiline comments do indeed cause the source
  65. line count to get incremented. I felt that the ANSI specification was a
  66. bit fuzzy in the above situation. The way I interpreted it was that a
  67. "source line" is a bit different from a "preprocessor directive line"
  68. -- as seen in the above example, a "preprocessor directive line" can
  69. indeed span multiple "source lines". Thus, the #line should mean that
  70. the next _source line_ should have the line number specified in the
  71. directive: in this case the next source line is a part of the
  72. directive itself!
  73.  
  74.     Thus, according to my interpretation, my preprocessor is doing
  75. the right thing.
  76.  
  77.     Do knowledgeable readers agree or disagree? Do you not think
  78. that ANSI has left this a bit unspecified (so that both my
  79. preprocessor as well as gcc may be correct depending on the the
  80. interpretation)?
  81.  
  82.     Kindly send your valuable responses to me by E-mail.
  83.  
  84.  
  85. Regards,
  86.  
  87. --
  88. Soumya
  89.